home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / bgp / bgp-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  200 lines

  1. Editor's Note:  Minutes received 7/29
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by David Bolen/ANS
  6.  
  7. Minutes of the Border Gateway Protocol Working Group (BGP)
  8.  
  9. During the first of two BGP Working Group sessions, the majority of the
  10. time was spent discussing two documents -- the Internet Draft for BGP4
  11. (Yakov Rekhter and Tony Li), and BGP4 <-> OSPF Interaction Document
  12. (Kannan Varadhan) -- with a small portion of time devoted to discussing
  13. BGP Communities proposal (Yakov Rekhter and Tony Li).
  14.  
  15. BGP Communities Discussion
  16.  
  17. To start the meeting off, Tony Li presented the BGP Communities proposal
  18. (the use of a new path attribute to ``color'' a route), as previously
  19. posted to the BGP mailing list.  The use of communities is intended to
  20. help solve the current AUP (acceptable use policy) routing problem by
  21. distributing some of the policy information (as kept in the NSFNET
  22. policy database) as a community associated with a route.  The document
  23. predefines communities for research, education and commercial ASs.  A
  24. community may be associated with a route by the source of that route, or
  25. may be added or augmented by any transit router (so a provider can
  26. ``stamp'' a route on behalf of a customer).  While not a truly general
  27. solution (i.e., it does not help in cases where customers are using
  28. default routes), it may still prove beneficial in a large number of
  29. cases.  The general consensus of the Group was that the proposal was
  30. worthwhile and would be useful to move forward.
  31.  
  32. BGP-4 Protocol Specifications Discussion
  33.  
  34. Next, the current BGP4 Internet Draft was discussed - driven primarily
  35. by comments from M. Craren of Proteon, as he had questions about the
  36. document after having examined it in anticipation of implementing BGP
  37. for Proteon.  The Working Group directly answered several of the simpler
  38. BGP implementation questions, while some points resulted in proposed
  39. changes to the draft, as follows:
  40.  
  41.  
  42.    o Section 2 Introduction
  43.  
  44.       -  Revise to indicate that BGP4 no longer absolutely carries full
  45.          AS path information (due to the possible use of the new
  46.          ATOMIC_AGGREGATE attribute by intermediate routers).
  47.  
  48.       -  Provide additional clarification as to what routes may be
  49.          advertised by a BGP speaker (namely that it cannot advertise
  50.          routes that it is not using).
  51.  
  52.       -  Add a description of the FIB (forwarding information base).
  53.  
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61.    o Section 3.2 (c) Routing Information Bases - Adj-RIBs-Out
  62.  
  63.       -  Clarify that an outgoing policy (for the selection of routes to
  64.          be advertised to a neighbor) is applied only for ``external''
  65.          neighbors.
  66.  
  67.    o Section 6.1 Message Header error handling
  68.  
  69.       -  Remove the use of the ``flash'' qualifier to discuss update
  70.          messages.  Its use was thought to be a holdover from the early
  71.          GATED implementation of BGP.
  72.  
  73.  
  74. There were also a few simple grammatical changes pointed out.  The BGP-4
  75. document will be updated and released as a new version of the Internet
  76. Draft.
  77.  
  78. BGP-4 <-> OSPF Interaction Discussion
  79.  
  80. Kannan Varadhan then held a discussion of the updates necessary to his
  81. BGP<->OSPF interaction document to bring it in line with BGP4.  For the
  82. most part the changes were to reflect the use of NLRI (Network Layer
  83. Reachability Information) within the BGP4 draft, since BGP4 carries IP
  84. prefixes rather than ``class''-based network numbers.
  85.  
  86. One point brought up was that the document states that the OSPF router
  87. ID must be set to an interface address.  OSPF does not require this, but
  88. the OSPF and BGP router IDs must be identical and BGP does set this
  89. requirement.  It was agreed that the appropriate change to make was to
  90. update the BGP4 draft so that the router ID can be chosen as any address
  91. assigned to the router, but need not be associated with a physical
  92. interface.  The BGP<->OSPF interaction document would then be updated to
  93. include the same restriction.
  94.  
  95. Kannan will also be releasing an updated version of his document.
  96.  
  97. The second BGP Working Group session was Chaired by Tony Li, and spent
  98. most of the time discussing the creation of a BGP4 usage document.  The
  99. document is still to be done, but it was agreed that it would be very
  100. similar to the current BGP usage document, but extended to discuss BGP4
  101. aggregation rules and requirements, and how to handle interactions with
  102. protocols that did not understand aggregated routes (such as EGP and
  103. older versions of BGP).
  104.  
  105. One issue that was left undecided (after a lengthy discussion) was what
  106. aggregation should be performed by a BGP4 implementation by default.
  107. There was no clear consensus on what option would be less likely to
  108. cause problems either for existing systems or for the site using BGP4
  109. itself.
  110.  
  111. Some time was also spent on the BGP Communities proposal and on the BGP
  112. MIB document.  The Group agreed that the BGP Communities document should
  113.  
  114.  
  115.                                    2
  116.  
  117.  
  118.  
  119.  
  120.  
  121. proceed forward, probably with a release as an Internet Draft.  The MIB
  122. document requires updating to include references to NLRI within BGP4's
  123. routes rather than networks as well as changes in the format of the
  124. AS_PATH attribute and creation of new path attributes.  It was agreed to
  125. make the necessary changes.
  126.  
  127. Attendees
  128.  
  129. Nagaraj Arunkumar        nak@3com.com
  130. Dennis Baker             dbaker@wellfleet.com
  131. Tony Ballardie           a.ballardie@cs.ucl.ac.uk
  132. John Ballard             jballard@microsoft.com
  133. Tony Bates               tony@ean-relay.ac.uk
  134. Jordan Becker            becker@nis.ans.net
  135. David Bolen              db3l@nis.ans.net
  136. Steve Buchko             stevebu@newbridge.com
  137. Ross Callon              callon@bigfut.enet.dec.com
  138. James Carlson            carlson@xylogics.com
  139. William Carter           carter@ctron.com
  140. Frank Chen               frankc@casc.com
  141. Dean Cheng               dean@sun2.retix.com
  142. Robert Ching             natadm!rching@uunet.uu.net
  143. Chris Chiotasso          chris@artel.com
  144. Henry Clark              henryc@oar.net
  145. Rob Coltun               rcoltun@ni.umd.edu
  146. Jim Comen                comenj@interlan.interlan.com
  147. Michael Craren           mjc@proteon.com
  148. Steven Fancher           sfancher@ursa-major.spdcc.com
  149. Dennis Ferguson          dennis@mrbill.canet.ca
  150. Peter Ford               peter@lanl.gov
  151. AnneMarie Freitas        afreitas@microcom.com
  152. Vince Fuller             vaf@stanford.edu
  153. Der-Hwa Gan              dhg@nsd.3com.com
  154. Martin Gray              mg@spider.co.uk
  155. Dimitry Haskin           dhaskin@bbn.com
  156. Dwight Jamieson          djamies@bnr.ca
  157. Matthew Jonson           jonson@server.af.mil
  158. Dan Jordt                danj@nwnet.net
  159. George Kajos             kajos@coral.com
  160. Mark Knopper             mak@merit.edu
  161. Mark Knutsen             knutsen@almaden.ibm.com
  162. John Krawczyk            jkrawczy@wellfleet.com
  163. Alan Kullberg            akullber@bbn.com
  164. John Labbe               labbe@merit.edu
  165. Tony Li                  tli@cisco.com
  166. Anthony Lisotta          lisotta@nas.nasa.gov
  167. Robin Littlefield        rlittlef@wellfleet.com
  168. Kent Malave              kent@chang.austin.ibm.com
  169. Matt Mathis              mathis@a.psc.edu
  170. Dennis Morris            morrisd@imo-uvax.disa.mil
  171. Kraig Owen               tko@merit.edu
  172. Eric Peterson            elpeterson@eng.xyplex.com
  173. Yakov Rekhter            yakov@watson.ibm.com
  174.  
  175.                                    3
  176. ^L
  177.  
  178.  
  179.  
  180.  
  181. April Richstein          abm@tycho.ncsc.mil
  182. Martin Schulman          mas@loyola.edu
  183. Hellen Sears             sears@interlan.interlan.com
  184. Erik Sherk               sherk@sura.net
  185. Marten Terpstra          terpstra@ripe.net
  186. Linda Tom                toml@interlan.interlan.com
  187. Kannan Varadhan          kannan@oar.net
  188. Ross Veach               rrv@uiuc.edu
  189. Curtis Villamizar        curtis@ans.net
  190. John Vollbrecht          jrv@merit.edu
  191. David Waitzman           djw@bbn.com
  192. Luanne Waul              luanne@wwtc.timeplex.com
  193. Honda Wu                 natadm!honda@uunet.uu.net
  194.  
  195.  
  196.  
  197.                                    4
  198.  
  199.  
  200.